Placeholder case nodes and child case nodes in a case model

ABSTRACT

Case management systems and techniques are disclosed. In various embodiments, an indication to create a case instance is received. A case model definition is parsed to determine a hierarchical data model to be used to create the case instance and a placeholder data to be associated with a case node comprising the hierarchical data model. The case model definition is used to create the case instance, including by associating the placeholder data with the case node in the case instance as created.

CROSS REFERENCE TO OTHER APPLICATIONS

This application is a continuation of, and claims a benefit of priorityunder 35 U.S.C. 120 of the filing date of U.S. patent application Ser.No. 14/502,132, filed Sep. 30, 2014, entitled “PLACEHOLDER CASE NODESAND CHILD CASE NODES IN A CASE MODEL,” claims priority to U.S.Provisional Patent Application No. 62/031,590, filed Jul. 31, 2014,entitled “CASE MODEL CREATION, CONTENT, AND BEHAVIOR,” the entirecontents of which are hereby expressly incorporated by reference for allpurposes.

BACKGROUND OF THE TECHNOLOGY

Case management systems, software, and/or cloud-based or otherelectronically-provided case management services (collectively, “CaseManagement Systems”) are used to automate the management of complex setsof documents or other content and associated business or otherprocesses, particularly in situations in which the documents or othercontent that may need to be managed for respective particular instancesof a case model/type (e.g., a loan application) may not be the same foreach instance and the processing required and/or selected to beperformed may not be the same for each instance.

A case model (“Case Model”) typically describes a type of case,instances of which are to be managed by a Case Management System. Asopposed to very structured business process that defines a predeterminedwork flow that does not vary from instance to instance, using a CaseModel one can model ad hoc actions and define responses thereto withmini workflows, enabling the processing of respective instances of aCase Model to be determined dynamically at runtime based, e.g., onevents, context data, user input, dynamic evaluation of documents orother content, etc. As a result, each instance of a Case Model (e.g.,the respective loan applications of different applicants) may follow itsown course as determined at each step by processing as defined inapplicable portions of the Case Model.

BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments of the technology are disclosed in the followingdetailed description and the accompanying drawings.

FIG. 1 is a flow chart illustrating an example embodiment of a processto perform case management.

FIG. 2 is a block diagram illustrating an example embodiment of a casemanagement system and environment.

FIG. 3 is a block diagram illustrating an example embodiment of a casemanagement system.

FIG. 4 is a diagram illustrating an example embodiment of a process andsystem to create and/or provide access to case management instances.

FIG. 5 is a flow chart illustrating an example embodiment of a processto receive and store a case model.

FIG. 6 is a flow chart illustrating an example embodiment of a processto receive and store a case model.

FIG. 7 is a block diagram illustrating an example of a hierarchical datamodel in an embodiment of a case management system.

FIG. 8 is a block diagram illustrating an example of a hierarchical datamodel in an embodiment of a case management system

FIG. 9 is a block diagram illustrating an example of a hierarchical datamodel and associated state machine in an embodiment of a case managementsystem.

FIG. 10 is a block diagram illustrating an example of a state machinedefined for a case node in an embodiment of a case management system.

FIG. 11 is a flow chart illustrating an example embodiment of a processto define a state machine for a case node in an embodiment of a casemanagement system.

FIG. 12 is a block diagram illustrating an example embodiment of ahierarchical/nested container comprising a case management instance thatincludes placeholders.

FIG. 13 is a block diagram illustrating an example embodiment of a casemodel that includes placeholders.

FIG. 14 is a flow chart illustrating an example embodiment of a processto include placeholders in a case instance.

FIG. 15 is a flow chart illustrating an example embodiment of a processto use and/or replace placeholders in a case instance.

DETAILED DESCRIPTION

The technology described herein can be implemented in numerous ways,including as a process; a system; a computer program product embodied ona computer readable storage medium; and/or a processor, such as aprocessor configured to execute instructions stored on and/or providedby a memory coupled to the processor. In general, the order of the stepsof disclosed processes may be altered within the scope of thetechnology. Unless stated otherwise, a component such as a processor ora memory described as being configured to perform a task may beimplemented as a general component that is temporarily configured toperform the task at a given time or a specific component that ismanufactured to perform the task. As used herein, the term ‘processor’refers to one or more devices, circuits, and/or processing coresconfigured to process data, such as computer program instructions.

A detailed description of one or more embodiments of the technology isprovided below along with accompanying figures that illustrate thetechnology. The technology is described in connection with suchembodiments, but the technology is not limited to any embodiment. Thescope of the technology is limited only by the claims and the technologyencompasses numerous alternatives, modifications and equivalents.Numerous specific details are set forth in the following description inorder to provide a thorough understanding of the technology. Thesedetails are provided for the purpose of example and the technology maybe practiced according to the claims without some or all of thesespecific details.

Providing placeholder case nodes and sub nodes in a case model isdisclosed. In various embodiments, any case node or case leaf nodecomprising a hierarchical/nested container model of a case model may bedesignated as a placeholder. When an instance of case model or aspecific case node is created, placeholders are created for each of thecontainers or leaf nodes (e.g., documents) marked as such in the casemodel. In various embodiments, by virtue of creating these placeholders,there will be some actions/behavior available on those case model nodes,such as fill the placeholders (e.g., with meta-data or other attributes,a document or other content, etc.), due dates by which thoseplaceholders need to be filled, etc.

FIG. 1 is a flow chart illustrating an example embodiment of a processto perform case management. In the example shown, a case modeldefinition is received and stored (102). The case model definition isused to create new instances based on the case model, sometimes referredto herein as “case instances” or “case management instances”, and/or toprovide access to previously-created instances (104). For example, acase model may be defined and stored for a loan application andassociated processes. Case instances may be created based on the casemodel and each respective case instance used to manage a correspondingloan application, for example by different respective loan applicants.

A case model typically describes a case management system. Using a casemodel, one can model ad hoc actions with mini workflows, for example, asopposed to very structured process that defines an end-to-end businessworkflow. In various embodiments, a case model comprises ahierarchical/nested container model (sometimes referred to herein as a“hierarchical data model”), and may in addition define case roles, casephases (states), and/or permissions. In some embodiments, permissionsmay be defined for each case node and/or level in the hierarchy, and mayvary in some embodiments based at least in part on the respective phases(states) of a state machine defined for a case node.

In various embodiments, a case model may include a hierarchical/nestedcontainer model. This model represents how the data with in a case isorganized and what data is captured during runtime. Each node in thehierarchy is sometimes referred to herein as a “case node”. Case nodesat the lowest level of a case model hierarchy may be referred to as“case leaf nodes” or simply “leaf nodes”. “Case leaf nodes” in variousembodiments may point to a specific business object or document type.

The term “case role” is used herein to refer to user roles that havebeen defined in a case model. In various embodiments, users may beassigned to case roles with respect to instances of a case model, and ateach case node in the case model permissions may be designated byreference to one or more case roles. During runtime in some embodimentsmembers may be added or removed from these roles at case node instancescorresponding to respective instances of a type of case as defined in acase model.

In various embodiments, at each case node a metadata model that definesone or more traits and/or associated behavior may be defined.

In various embodiments, a case model as described herein may be createdusing a domain-specific or other development module or tool. Forexample, reusable elements, such sample case nodes typical of those usedin the domain (e.g., documents, case roles, behaviors, etc. Typicallyassociated with a loan application process, a new drug approvalapplication, etc.), primitives usable to define a state machine and/orassociated processing for respective case nodes, etc., may be provided.For example, an application programming interface (API) may be defined,and/or a visual or other case model development tool may be provided.

In various embodiments, a case model definition is embodied in an xml orother structured data file. A case management system and/or platform isprovided, which is configured (e.g., by software) to load a case modeldefinition, parse the definition, and create an instance of the casemodel based on the definition. Instance-specific attributes and/or stateinformation or other metadata may be stored in a case model instancedata store, e.g., a database. At runtime, the case model definition fileand the case model instance data for a given instance are used by thedisclosed case management system to implement the case model instance,including by performing processing and managing case model instanceassociated content per the case model definition, in light of thecurrent values of the case model instance data for that instance.

FIG. 2 is a block diagram illustrating an example embodiment of a casemanagement system and environment. In the example shown, client systems202 are connected via a network 204, e.g., the Internet, to a casemanagement system 206. In various embodiments, the case managementsystem 206 may be configured to implement the process of FIG. 1. Casemanagement system 206 uses case models stored in data storage 208 toprovide case management services with respect to case managementinstances, the instance variable data values of which also are stored,in this example, in data storage 208. For example, one or more ofclients 202 may connect via network 204 to case management system 206 toobtain access to case management services. For example, case managementsystem 206 may expose a “case management system as a service”, e.g., asa web service, enable clients 202 to connect to case management system206, create case management instances based on case models stored indata storage 208. The users of client system 202 may be prompted toprovide data values and/or other user input to populate case managementinstances with metadata, user data, documents, etc., and/or such otheruser input as may be required to advance case instances through casemanagement processing as defined in the case model.

In the example shown in FIG. 2, a case model developer system 210, e.g.,a client computer system, also can connect to case management system 206via network 204. In some embodiments, a case model development userinterface and/or service may be accessed and used to define a casemodel. For example, a visual or other developer tool may be presented toenable a developer using client system 210 to define a case model andcause the case model to be stored in data storage 208 and deployed bycase management system 206. In some embodiments, deployment of a casemodel includes making the case model available to be used to create casemanagement instances based on the model, and to use the case model toperform with respect to each such instance the case managementprocessing as defined in the case model.

In various embodiments, a case model may indicate one or more contentobjects to be associated with respective instances of a case model. Thecase model may include metadata and associated behaviors to enableinstance-specific content objects (e.g., documents) to be associatedwith case leaf nodes of a case instance. In the example shown in FIG. 2,content objects may be accessed via a content management system 212configured to manage content objects stored in an associated contentrepository 214. In various embodiments, case management system 206 maybe configured to use instance variables associated with a given caseinstance and metadata and/or behaviors defined in an associated casemodel to interact programmatically with content management system 212 toobtain and/or manage documents or other content objects associated witha case instance. In some embodiments, case management system 206 may beconfigured, e.g., via the case model, to invoke services and/or otherfunctionality of content management system 212 with respect to suchdocuments or other content objects.

FIG. 3 is a block diagram illustrating an example embodiment of a casemanagement system. In some embodiments, the case management system ofFIG. 3 corresponds to case management system 206 of FIG. 2. In theexample shown, case management system 206 includes a networkcommunication interface 302, such as a wireless or other networkinterface card, to provide network connectivity, e.g., to network 204 ofFIG. 2. A case model development module 304 is accessible to developersvia network communication interface 302 and may be used to create and/ormodify case model definitions. In some embodiments, a visual or otheruser interface is provided, via network communication interface 302, toenable case models to be created and/or modified. For example, adeveloper may use a browser to access the developer user interface insome embodiments. Case model definitions are stored by case modeldevelopment module 304 by using a backend database (or other datastorage) interface 306 to store the case model(s) in case model store308.

Referring further to FIG. 3, the case management system 206 includes acase management module 310. In various embodiments, case managementmodule 310 includes functionality to enable users, e.g., users of clientsystems 202 of FIG. 2, to create and/or use case management instancesbased on case models stored in case model store 308. Case managementmodule 310, for example, may expose a web or other interface to remoteusers and may receive via said interface a request to create and/oraccess a case instance. Case management module 310 uses databaseinterface 306 to obtain an associated case model definition from casemodel store 308, to use the case model to instantiate case instances.Instance variables are stored by case management module 310 in caseinstance data store 312.

FIG. 4 is a diagram illustrating an example embodiment of a process andsystem to create and/or provide access to case management instances. Insome embodiments, the process of FIG. 4 may be implemented by a casemanagement system and/or a component thereof, such as case managementmodule 310 of FIG. 3. In the example shown, case management system 400receives a request 402 to create or access a case management instanceand invokes instantiation process 404. Instantiation process 404 uses acase model definition 406 associated with the request, e.g., a casemodel indicated explicitly and/or otherwise associated with datacomprising the request 402, and case management instance data 408associated with the case management instance, to instantiate and provideaccess to a case management instance 410.

In various embodiments, a case model definition such as model definition406 may include an eXtensible Markup Language (XML) file or otherstructured data, which the case management system is configured to parseand use to construct case instances based on the case model. Forexample, the hierarchical data structure may be defined, along withmetadata and associated behaviors for each case node. A case managementinstance, such as case management instance 410, may include an in memoryinstance of a data structure defined in case model definition 406, whichis used to store instance variables, such as instance data 408 in thisexample.

FIG. 5 is a flow chart illustrating an example embodiment of a processto receive and store a case model. In some embodiments, the process ofFIG. 5 is used to implement step 102 of FIG. 1 and is performed by acase management system, such as case management system 206 of FIG. 2,e.g., case model development module 304 of FIG. 3. In the example shown,an indication that a new case model is to be defined is received (502).A problem domain-specific developer interface to be used to define thecase model is provided (504). For example, in some embodiments adeveloper may indicate in a request to define a new case model, and/ormay be prompted to indicate, a “problem domain” with which the casemodel is associated, such as a loan application, an employmentapplication, a product development or other business project, ahealthcare or other patient, a claim for reimbursement or benefits, or amatter being handled by a professional or personal service provider,such as a lawsuit, home renovation project, etc. In various embodiments,the problem domain-specific developer interface provides access toproblem domain-specific elements to assist the developer in defining thecase model. For example, a loan application typically is initiated by aloan applicant submitting an application, and typically involvesgathering information to verify and evaluate the applicant's identity,financial assets, income, creditworthiness, etc. In some embodiments, atemplate may be provided to be used as a starting point. The developeruses visual or other tools to customize the template as desired todefine a case model.

Once the developer has completed and submitted the case modeldefinition, the case model definition is received, stored, and deployed(506). In some embodiments, a runtime representation of the definitionis processed, e.g., upon submission by the developer, to generate an XMLor other structured data file that embodies the case model as defined.Deployment in various embodiments includes making the case modeldefinition available to be used to instantiate case management instancesbased on the case model, e.g., individual loan application cases.

FIG. 6 is a flow chart illustrating an example embodiment of a processto receive and store a case model. In some embodiments, the process ofFIG. 6 is included in step 506 of FIG. 5. In the example shown, adefinition of a hierarchical/nested data model is received (602). Forexample, a user interface that enables a developer to drag and drop casenodes onto a canvass and to indicate hierarchical relationships betweencase nodes may be provided and used by the developer to define ahierarchical/nested data model. A definition of case roles is receivedand stored (604). For example, a “loan application” case model mayinclude user roles such as “loan initiator”, “underwriter”, “appraiser”,etc. For each case node in the hierarchical/nested data model, adefinition of metadata, behaviors, content (e.g., documents),states/phases (and transitions between states/phases), and/orpermissions (e.g., by case role) is received (606). For example, invarious embodiments a developer interface may be provided to enable adeveloper to select a case node and be presented with an interface todefine a state machine for that case node.

FIG. 7 is a block diagram illustrating an example of a hierarchical datamodel in an embodiment of a case management system. In variousembodiments, a case model, such as one defined using the processes ofFIGS. 5 and 6, may include a hierarchical/nested container model, suchas the one shown in FIG. 7. In the example shown, hierarchical/nestedcontainer model 700 includes a root node 702 at a first (highest)hierarchical level. At a first hierarchical level below the root node,nodes 704 and 706 are included. Finally, in a lowest hierarchical level(in this example), node 704 has two “case leaf nodes” 708 and 710. Invarious embodiments, metadata, behaviors, permissions, etc. that havebeen defined for a case node extend (or in some embodiments may at theoption of the case model developer be extended) to child case nodes ofthe case node at which such metadata, behaviors, permissions, etc. havebeen defined.

FIG. 8 is a block diagram illustrating an example of a hierarchical datamodel in an embodiment of a case management system, such as casemanagement system 206 of FIG. 2. In particular, a hierarchical/nestedcontainer model for a home loan application is illustrated. In theexample shown, each instance of a “loan” case includes a root node 802and two first level sub-nodes 804 and 806, in this example one (804) forfinancial information of the applicant and associated processing, andanother (806) for information and processing associated with the home tobe purchased using the loan. The “applicant information” sub-node 804includes a first case leaf node 808 for Forms W-2 and a second case leafnode 810 for the applicant's tax returns. “Property” sub-node 806includes case leaf nodes 812, 814, and 816 for the title report,appraisal report, and home inspection report, respectively. In variousembodiments, the case model definition may include for each case node adefinition of metadata and/or behaviors for that case node. For caseleaf nodes, such as case leaf nodes 808, 810, 812, 814, and 816, thecase model definition may include information regarding documents orother content objects to be associated with such nodes, including insome embodiments an identification of a storage location in which suchdocuments are to be stored, e.g., in a content repository such asrepository 214 of FIG. 2 associated with a content management systemsuch as content management system 212 of FIG. 2.

FIG. 9 is a block diagram illustrating an example of a hierarchical datamodel and associated state machine in an embodiment of a case managementsystem. In various embodiments, the hierarchical data model andassociated state machine of FIG. 9 may be included in a case modeldefinition defined and/or deployed via a case management system such ascase management system 206 of FIGS. 2 and 3. In the example shown, astate machine 902 has been defined for and associated with case node 704of hierarchical/nested container model 700 of FIG. 7.

In various embodiments, for any case node within the hierarchical/nestedcontainer model, a state machine can be defined and the actions that canbe used to transition between different phases/states of the statemachine defined for that case node may be specified. These actions couldbe used during runtime to transition between states.

In the example shown in FIG. 9, a state machine 902 has been defined andassociated with a specific case node in the hierarchical model shown inFIG. 7, specifically node “F11” (704). In various embodiments, adocument or other content associated with node “F11”; traits, such asmetadata and/or associated behavior associated with node “F11”; etc. maybe transformed, reviewed, and/or otherwise involved with processing thatmay result, in a given case model instance, in transitions being madebetween states of the state machine 902 defined for case node “F11” inthis example.

In various embodiments, enabling a state machine to be defined andassociated with a case node comprising a hierarchal/nested containermodel provides a flexible, dynamic framework within which ad hoc actionsand/or information can be responded to, in a manner determineddynamically based on the circumstances of a given instance of a case,with the result that the actions and/or processing performed at a givencase node, and/or the consequences of such actions and/or processing,may be different for one instance of the case model than for anotherinstance of the case model.

In various embodiments, a state machine engine may be included in a casemanagement system, such as case management system 206 of FIG. 2, toenable a state machine defined for a case node, such as state machine902 of FIG. 9, to be implemented and associated functionality to beprovided. For example, in some embodiments, case management module 310of FIG. 3 may include a state machine engine. In some embodiments, thestate machine engine may receive and parse state machine definitionportions of a case model definition, and may use such portions to createand manage runtime data structures associated with the respectivedefined states (phases) of the state machine and transitions betweenthem. In some embodiments, state variables associated with a currentstate of a case node-specific state machine for a given instance of acase model may be stored persistently with other case managementinstance data, for example in a case instance data store such as datastore 312 of FIG. 3.

FIG. 10 is a block diagram illustrating an example of a state machinedefined for a case node in an embodiment of a case management system. Invarious embodiments, the state machine of FIG. 10 may be included in acase model definition defined and/or deployed via a case managementsystem such as case management system 206 of FIGS. 2 and 3. In theexample shown, state machine 1000 includes an “open” state 1002,associated for example with beginning processing of a received document,such as one created locally, uploaded, or otherwise provided by a user.In the example shown, a transition out of the “open” state 1002 mayoccur upon a “submit” option being selected, e.g., by a user, a businessprocess, an external service, etc. If the item was submitted with anindication that a “review” is required (e.g., a reviewer is named orotherwise indicated), the state machine transitions to a “pending” state1004, indicating the required review is pending. If no review isrequired, the state machine instead transitions directly to an“accepted” state 1006. If review was required and the reviewer “accepts”the item, a transition from “pending” state 1004 to “accepted” state1006 occurs. If instead the reviewer were to “reject” the item, in thisexample a transition from “pending” state 1004 to “rejected” state 1008would occur. From either “accepted” state 1006 or “rejected” state 1008,a “close” transition to a “closed” state 1010 could occur. Finally, inthis example, “reopen” transitions back to “open” state 1002 could occurfrom the “accepted” state 1006, “rejected” state 1008, and/or “closed”state 1010.

Note that for a given instance of a case model with which the statemachine 1000 of FIG. 10 is associated, the states through which thestate machine 1000 of FIG. 10 may transition for that instance may bedifferent than for one or more other instances. Also, for a giveninstance, depending on the state machine definition included in the casemodel definition, the user data associated with that instance atapplicable times, and potentially user actions and decisions made inresponse to case information, the state machine 1000 may be transitionedto/through a given state more than once (e.g., via the “reopen”transitions), potentially resulting in different outcomes of processingassociated with that state.

FIG. 11 is a flow chart illustrating an example embodiment of a processto define a state machine for a case node in an embodiment of a casemanagement system. In various embodiments, the process of FIG. 11 may beperformed by a case management system, such as case management system206 of FIGS. 2 and 3. For example, in some embodiments, a case modeldevelopment component such as case model development module 304 of FIG.3 may include a development tool and/or feature to enable a statemachine to be defined and associated with a case node, using the processof FIG. 11.

In the example shown in FIG. 11, an indication to define a state machinefor a case node is received (1102). For example, a developer using acase model definition tool, service, and/or interface may select a casenode and provide an input indicating that a state machine is desired tobe defined for and associated with the selected node. A developer userinterface to define a state machine for the case node is provided(1104). A definition of two or more states and transition(s) betweenthem is received (1106). A definition of permissions associated with therespective states, e.g., who may access content or metadata associatedwith the case node while the state machine is in that state, is received(1108). A definition of permissions associated with transitions betweenthe respective states, e.g., who may cause each transition to occur, isreceived (1110). In various embodiments, a state machine defined for acase node using the process of FIG. 11 may be included in the case modeldefinition as stored and deployed, e.g., in a corresponding portion ofan XML or other structured data file comprising the case modeldefinition.

In various embodiments, any case node or case leaf node comprising ahierarchical/nested container model of a case model may be designated asa placeholder. When an instance of case model or a specific case node iscreated, placeholders are created for each of the containers or leafnodes (e.g., documents) marked as such in the case model.

FIG. 12 is a block diagram illustrating an example embodiment of ahierarchical/nested container comprising a case management instance thatincludes placeholders. In some embodiments, a case model comprising adata model such as the one shown in FIG. 12 may be used by a casemanagement system, such as case management system 206 of FIGS. 2 and 3,to create and manage case instances. For example, a case instanceincluding placeholders, such as the one shown in FIG. 12, may be createdbased on a case model definition.

In the example shown in FIG. 12, hierarchical/nested container 1200 isassociated with an instance of a loan application case type. Thecontainer 1200 includes a root node 1202, labeled “Loan_123” in thisexample, for example to identify the instance as being of the type“Loan”. The label “Loan_123” in this example identifies the containerinstance 1200 as being associated with a specific instance of the “Loan”case type. Below the root node 1202, in this example, there aresub-nodes 1204 and 1210, labeled “Financial” and “Home inspection”,respectively. For example, the “Financial” sub-tree including node 1204and child nodes 1206, 1208, 1212, and 1214, may be used in variousembodiments to hold metadata, provide behaviors, and store documents(e.g., in leaf nodes 1212 and 1214) Likewise, the “Home inspection” node1210 has a leaf node 1216, which may be used, for example, to hold ahome inspection report or other document.

In the example shown in FIG. 12, placeholders have been created andstored for leaf nodes 1212, 1214, and 1216. In various embodiments, theplaceholders may comprise placeholder documents or other content items,or pointers to such content items. Placeholder documents or othercontent items, in various embodiments, are not actual user (e.g., loanapplicant) documents or data. Instead, the presence of such placeholdersenables associated behaviors to be performed. For example, in someembodiments presence of a placeholder document may trigger a behavior toprompt a user to replace the placeholder with a corresponding userdocument. For example, an expiration period or due date may becomeassociated with the placeholder upon instantiation, resulting in areminder being generated to replace the placeholder document prior toexpiration of the applicable period.

While in the example shown in FIG. 12 the placeholders are documentsassociated with case leaf nodes, in other embodiments a placeholder maybe included as a case node and/or as metadata and/or user dataassociated with a case node.

FIG. 13 is a block diagram illustrating an example embodiment of a casemodel that includes placeholders. In some embodiments, a case modelcomprising a data model such as data model 1300 shown in FIG. 13 may beused by a case management system, such as case management system 206 ofFIGS. 2 and 3, to create and manage case instances. For example, a caseinstance including placeholders, such as the one shown in FIG. 13, maybe created based on a case model definition.

In the example shown, a hierarchical/nested container instance 1300includes a root node 1302 and container nodes 1304 and 1306. Containernode 1304 includes a placeholder case leaf node 1308. The case leaf node1308 in this example comprises a placeholder document. In someembodiments, upon creation of a new instance of a “job application”based on the case model shown in FIG. 13, a placeholder document isassociated with the instance of case leaf node 1308 included in the caseinstance. The presence of the placeholder document associated with caseleaf node 1308 in various embodiments may result in associatedbehaviors, such as a notification to replace the placeholder with a formof identification that satisfies criteria defined in the case model ofFIG. 13, in this example.

In addition, in the example shown in FIG. 13 the container node 1306 ofcase model 1300 is a placeholder container node. In this example, thepresence of placeholder node 1306 in a case instance based on case model1300 may result in associated behaviors, such as preventing furtherprocessing until the placeholder container has been replaced with acontainer that satisfies requirements defined in the case model 1300.For example, upon creation of a new instance of a “job application”based on case model 1300, the case instance may include a placeholdercontainer corresponding to container node 1306 of FIG. 13, along withtwo placeholder documents 1310 and 1320. The case model 1300 may includea definition of requirements that the placeholder container 1306 andassociated placeholder documents be replaced by a container (e.g., afolder, archive, etc.) uploaded by the applicant and containing at leasttwo samples of the applicant's written work, to replace placeholderdocuments 1310 and 1312, in this example.

In some embodiments, not shown in FIG. 13, a placeholder container mayinclude a definition of requirements that must be satisfied by acontainer uploaded to replace the placeholder container, includingrequired content (e.g., documents), but may not necessarily includeplaceholder documents (or other case leaf nodes) in the placeholdercontainer.

FIG. 14 is a flow chart illustrating an example embodiment of a processto include placeholders in a case instance. In various embodiments, acase management system, such as case management system 206 of FIGS. 2and 3, may implement the process of FIG. 14. In some embodiments, theprocess of FIG. 14 may be used to create case instances that includeplaceholders, such as those shown in FIGS. 12 and 13.

In the example shown, upon receiving an indication to create a new caseinstance (1402), an associated case model is used to create a newinstance, including by populating nodes or sub-nodes with placeholdernodes, data, and/or documents, as indicated in the applicable case modeldefinition (1404). At each placeholder node, behavior(s) associated withpresence of the placeholder is/are exhibited, as defined in the casemodel definition (1406).

FIG. 15 is a flow chart illustrating an example embodiment of a processto use and/or replace placeholders in a case instance. In someembodiments, step 1406 of FIG. 14 may include the process of FIG. 15. Inthe example shown, a case node comprising a case instance is evaluatedto determine whether the case node is populated with data and/ordocuments or other content items, as required by the applicable casemodel definition (1502). If the node is not (fully) populated (1502),action is taken to cause the node to become populated (1504). Forexample, a user may be prompted to provide the required data. If thenode is populated (1504), a determination is made as to whether the nodeis populated with a placeholder, as opposed to user data (1506). Forexample, a flag or other data value may be set, e.g., at instantiation,to indicate that what the node has been populated with is a placeholder.If the node is populated with a placeholder (1506), one or morebehaviors associated with the presence of the placeholder are performed(1508). Once such behaviors have been performed, or if the node has beendetermined to have already been populated by user data (i.e., not aplaceholder), a determination is made as to whether processing is done(1510). In the case, for example, that a placeholder was determinedpreviously to have been present (1506), the process may advance to await period (1512), after which a further iteration of applicable onesof steps 1502, 1506, and 1508 may be performed, for example, todetermine whether the placeholder has been replaced with user data. Ifnot, in some embodiments a further (or repeat) behavior may be exhibitedat step 1508, for example a further or follow up notification to theuser to replace the placeholder with user data. Once processing is done(1510), e.g., the placeholder, if any, has been replaced by user data,the process ends.

In one further example, a case model to manage an engineeringdevelopment project that includes inputs to be provided by third partysuppliers may include placeholder container and/or placeholder documentnodes, e.g., to ensure deliverables from third party contributors arereceived, and that other aspects of the case proceed in a desiredsequence relative to receipt of such deliverables. For example, a casemodel may include a placeholder container node for an “ElectricalDeliverable” with two placeholder documents, such as “Wiring Diagram”with a due date of “10/10/2014” and “Supporting EngineeringSpecifications” with a due date of “11/10/2014”. These placeholders maybe considered to be filled when their respective documents are uploadedby the third party contractor. Until then there could a rule that wouldprevent submission of the Electrical Deliverable for review. Forexample, replacement of the placeholders could be a precondition for aphase/state transition, e.g., to “Pending Review” from “Open”, of astate machine associated with the case node and/or a parent case node.

Use of placeholder documents and/or other case nodes or sub-nodes invarious embodiments enables associated behaviors to be exhibited tofacilitate management of cases, e.g., even when applicable users havenot yet provided all required documents and/or other user data andcontent. In various embodiments, a placeholder node may be used toimpose requirements and exhibit other behaviors, such as requirementswhich must be satisfied by a document and/or container provided toreplace a placeholder, requiring that a placeholder be replaced prior toother processing advancing, etc., thereby providing a more fine degreeof control and management over the progress of each case.

Although the foregoing embodiments have been described in some detailfor purposes of clarity of understanding, the technology is not limitedto the details provided. There are many alternative ways of implementingthe technology. The disclosed embodiments are illustrative and notrestrictive.

What is claimed is:
 1. A method of managing a case, comprising:receiving an indication to create a case instance; parsing a case modeldefinition to determine a hierarchical data model to be used to createthe case instance and a placeholder data to be associated with a casenode comprising the hierarchical data model; and using the case modeldefinition to create the case instance, including by associating theplaceholder data with the case node in the case instance as created. 2.The method of claim 1, wherein the case instance includes a behavior,defined in the case model definition, that comprises taking an actionwith respect to the placeholder data.
 3. The method of claim 1, whereinthe placeholder data comprises a placeholder document.
 4. The method ofclaim 3, wherein the case instance includes a behavior, defined in thecase model definition, that includes taking an action associated withreplacing the placeholder is document with a corresponding documentassociated with the case instance.
 5. The method of claim 4, wherein theaction includes prompting a user to replace the placeholder documentwith a user document.
 6. The method of claim 1, wherein the placeholderdata comprises a placeholder case node.
 7. The method of claim 1,wherein the placeholder data comprises metadata associated with the casenode.
 8. The method of claim 1, further comprising receiving a user datato replace the placeholder data.
 9. The method of claim 8, furthercomprising replacing the placeholder data with the user data.
 10. Themethod of claim 1, further comprising receiving and storing the casemodel definition.
 11. The method of claim 10, wherein receiving andstoring the case model definition includes receiving, via a case modeldefinition interface, an indication to include the placeholder data inthe case model definition.
 12. A case management system, comprising: astorage device configured to store a case model definition; and aprocessor coupled to the storage device and configured to: receive anindication to create a case instance; parse the case model definition todetermine a hierarchical data model to be used to create the caseinstance and a placeholder data to be associated with a case nodecomprising the hierarchical data model; and use the case modeldefinition to create the case instance, including by associating theplaceholder data with the case node in the case instance as created. 13.The system of claim 12, wherein the placeholder data comprises aplaceholder document.
 14. The system of claim 13, wherein the caseinstance includes a behavior, defined in the is case model definition,that includes taking an action associated with replacing the placeholderdocument with a corresponding document associated with the caseinstance; and wherein the processor is further configured to take theaction as defined in the case model definition.
 15. The system of claim14, wherein the action includes prompting a user to replace theplaceholder document with a user document.
 16. The system of claim 12,wherein the processor is further configured to receive a user data toreplace the placeholder data.
 17. A computer program product to manage acase, the computer program product being embodied in a non-transitorycomputer readable storage medium and comprising computer instructionsfor: receiving an indication to create a case instance; parsing a casemodel definition to determine a hierarchical data model to be used tocreate the case instance and a placeholder data to be associated with acase node comprising the hierarchical data model; and using the casemodel definition to create the case instance, including by associatingthe placeholder data with the case node in the case instance as created.18. The computer program product of claim 17, wherein the placeholderdata comprises a placeholder document.
 19. The computer program productof claim 18, wherein the case instance includes a behavior, defined inthe case model definition, that includes taking an action associatedwith replacing the placeholder document with a corresponding documentassociated with the case instance.
 20. The computer program product ofclaim 19, wherein the action includes prompting a user to replace theplaceholder document with a user document.